% Created 2011-12-08 jeu. 19:55
\documentclass[13pt]{article}
      \usepackage[utf8]{inputenc}

      \usepackage[T1]{fontenc}

      \usepackage[francais]{babel}

      \usepackage{graphicx}

      \usepackage{hyperref}
 
      \usepackage{geometry}


\title{MaColoc - Dossier de conception système     }
\author{Renaud Bordaz \& Vincent Dardel \& Alexandra Nitu \& Oualid Rafiq}
\date{08 décembre 2011}

\begin{document}

\maketitle

\setcounter{tocdepth}{3}
\vspace*{1cm}

%\begin{changemargin}{2cm}{2cm}
%\setmarginsrb{1cm}{1cm}{1cm}{1cm}{0cm}{0cm}{0cm}{0cm}

\begin{figure}
\begin{center}
%    \input{input}
\includegraphics[height=4cm]{logo.png}
\end{center}
%\label{} 
%\caption{}
\end{figure}


%\end{changemargin}


\begin{figure}
\begin{center}
%\begin{right}
%    \input{input}
\includegraphics[height=2cm]{logos.png}
\end{center}
%\end{right}
%\label{} 
%\caption{}
\end{figure}




\begin{center}
\begin{tabular}{ll}
 Document               &  Dossier de Conception Système  \\
\hline
 Version                &  1.6                            \\
\hline
 Commencé               &  03 décembre 2011               \\
\hline
 Dernière modification  &  08 décembre 2011               \\
\hline
 Statut                 &  final                          \\
\hline
 Client                 &  enseignants M2PGI              \\
\end{tabular}
\end{center}




\newpage

\tableofcontents


\section{But et portée du document}
\label{sec-1}

Le présent document présente  les spécifications techniques du produit
logiciel MaColoc et est destiné à tout futur collaborateur.  

Après la présentation et  la justification des technologies utilisées,
il  donnera  un  aperçu  de  l'architecture globale,  en  montrant  la
relation des composants entre eux, puis détaillera chacun des éléments
décrits dans la partie précédente  afin d’obtenir une vue détaillée de
notre application.

\section{Technologies utilisées}
\label{sec-2}

Le site a été réalisé avec les technologies \textbf{Java Enterprise Edition} (JavaEE),
il a été déployé sur  le serveur d'application \textbf{Jonas} 5.3.0-M4, utilise
une base de  données (BD) \textbf{MySQL} et le framework  web \textbf{Java Server Faces}
(JSF version 1.2). 


La  technologie JavaEE  est un  bon  choix car  c'est une  plate-forme
logicielle  robustesse  pour   les  applications  d'entreprise.   Elle
combine les  avantages du langage Java avec  l'expérience acquise dans
le développement au cours des 15 dernières années.


De  plus elle  est  Open Source,  donc  bénéficie du  dynamisme de  la
communauté et ne requiert pas l'achat de licence d'utilisation.


JSF  représente l'aboutissement  des servlet  et de  JSP dans  un même
framework web,  il était difficile  de ne pas l'utiliser.   Nous avons
utilisé la version  1.2 au lieu de la 2.0 car  cette dernière est pour
les EJB version 3.1.

Nous  utilisons  également des  composants  de l'implémentation  \href{http://www.primefaces.org/showcase/ui/home.jsf}{Prime Faces}   de  JSF   car  elle   est   éprouvée  et   plus  évoluée   que
l'implémentation de base.


Nous  avons préféré  le xhtml  au jsp  car, depuis  fin 2009,  jsp est
découragé depuis JSF 2.0. En effet le xhtml est plus flexible.

On  a  choisi  de  sécuriser l’authentification  des  utilisateurs  en
utilisant  le framework  \textbf{JAAS} (Java  Authentication  and Authorization
Service), inclus dans le .jar de JavaEE.


\underline{Remarque} : nous  avons choisi de franciser les  noms de fichiers, de
classes  et de  méthodes,  tout en  gardant  les préfixes  get et  set
(indispensable pour JavaEE et JSF).  

 
\section{Architecture système}
\label{sec-3}

\subsection{Fonctionnement général du site}
\label{sec-3.1}

MaColoc  est  un  site   internet  de  recherche  de  colocation.  Les
utilisateurs peuvent naviguer sur  le site pour consulter les annonces
et doivent  s'inscrire pour  en poster une.  Lors de  l'inscription on
distingue deux types d'utilisateurs :  ceux qui cherchent une place et
ceux qui en proposent une. De plus, nous devons distinguer les comptes
administrateurs. 


Chaque utilisateur  peut publier des  annonces le concernant  (soit en
tant  que “chercheur”  soit en  tant que  “propriétaire”). Lors  de sa
recherche, il peut aussi marquer des annonces pour les ajouter dans sa
liste d'annonces favorites.


MaColoc  permet de  réaliser toutes  les opérations  nécessaires  à la
recherche d'une colocation gratuitement, soit : 
\begin{enumerate}
\item chercher des offres (par ville, etc)
\item consulter les informations de contact
\item publier une annonce
\end{enumerate}
De  plus,  MaColoc  reprend   le  concept  d'options  facultatives  et
payantes.  Ainsi pour  chaque  annonce, on  associe  une ou  plusieurs
options payantes. L'achat des options  payantes est géré par un panier
électronique,  identique   à  toutes  les   applications  de  commerce
électronique. 


Nous devons  donc stocker  dans une base  de données  les informations
relatives à nos utilisateurs et  à leurs annonces. Les Enterprise Java
Beans (EJB)  reprennent l'architecure  présentée dans le  diagramme de
classes.  Le panier  sera implémenté  en  tant que  bean session  (non
persistant en BD). 

Chaque bean  entity (persistant) est  interfacé par un  bean stateless
(ou un stateful).

\subsection{Schéma  PAC}
\label{sec-3.2}

Notre  architecture   se  base   sur  \textbf{le  modèle   PAC}  (Présentation,
Abstraction, Contrôle).

\begin{itemize}
\item \textbf{Présentation} : cette couche est représentée par les pages xhtml qui
 correspondent à l’interface avec laquelle l’utilisateur interagit.
\item \textbf{Abstraction} : représenté par la façade et les entités Beans qui traitent les données et
  assurent l’interaction avec la base de données.
\item \textbf{Contrôle} :  représenté par les managed beans, qui permettent de gérer les
 événements  reçus de  la part  de  l’utilisateur et  de produire  les
 actions à effectuer.
 Les managed beans sont spécifiques à JSF.


  \begin{figure}
  \begin{center}
  %    \input{input}
  \includegraphics[height=6cm]{pac.png}
  \end{center}
  %\label{} 
  \caption{Architecture PAC}
  \end{figure}
\end{itemize}
Nous allons examiner ci-dessous l'architecture de la partie client et de la partie serveur.

\subsection{Architecture de la partie Client}
\label{sec-3.3}

Le  client léger  est  fait de  pages  xhtml qui  appellent, dans  des
balises JSF (taglibs), les managed beans. Les managed beans manipulent
la BD à travers des beans stateless.



\underline{Remarque}:  nous n'avons  pas de  client  lourd car  MaColoc n'a  pas
besoin   de   ravitaillement  en   produits,   comme   c'est  le   cas
habituellement  dans les  sites  de commerce  électronique. La  partie
d'administration  permet de  spécifier les  attributs caractéristiques
aux options  (durée de  validité, prix, …),  et de créer  de nouvelles
options (si l'implémentation l'a prévu).  

\subsubsection{Pages xhtml}
\label{sec-3.3.1}


Les pages xhtml constituent la  présentation de notre modèle.  Elles s’occupent
 de la partie présentation  des données et assurent l’aspect dynamique
 de l’application  en n’affichant  que les informations  demandées par
 l’utilisateur.

Nous  utilisons  un  ensemble   de  pages  xhtml  dont  principalement
CompteLogin.xhtml pour  le login, ChercheurAnnoncesNouvelle.xhtml pour
créer une nouvelle  annonce chercheur, AnnoncesRecherche.xhtml qui est
la page principale pour consulter et rechercher des annonces.

Les  pages  xhtml  communiquent  avec  les managed  beans  (des  beans
session).   Lorsqu'il faut  inter-agir  avec la  base  de données,  le
managed bean  récupère l'instance du bean stateless  (stateful pour le
panier) et utilise ses méthodes pour accèder à la BD.

\subsubsection{Managed beans}
\label{sec-3.3.2}



Les managed beans font partie de la partie contrôleur de notre
application. Ils permettent de

traiter  les évènements reçus  et de  générer les  actions nécessaires
pour répondre aux besoins
de l’utilisateur.

 Les managed beans principaux que nous utilisons sont :
\begin{itemize}
\item \textbf{Utilisateur}  : pour créer  un nouvel utilisateur  (chercheur ou
  propriétaire). C'est un bean de type session.
\item \textbf{Annonces} : permet de chercher des annonces et à un utilisateur
  connecté d'en créer et de modifier les siennes.
\item \textbf{CompteLogin} : permet de se connecter de manière sécurisée, en
  gérant correctement le panier.
\item \textbf{Admin}   :  permet  de  realiser  tous   les  operations  liées
 à l’administrateur ( affichage de tous les annonces, suppression
 d’un annonce, modification et suppression des options payantes).
\item \textbf{Panier} : gère le panier d’un client identifié (ajout d'une ou
  plusieurs options payantes associées aux différentes annonces, faire
  le total à  payer, réaliser le paiement, vider  le panier etc.).  Ce
  managed  bean associe  à  la  session client  une  instance du  bean
  PanierStateful.   Grâce  à  cette  association, à  chaque  opération
  effectuée  sur le panier,  les modifications  sont envoyées  au même
  bean  de type PanierStateful  sur le  serveur.  Donc  le managedbean
  Panier  joue  le  rôle   de  client  pour  le  PanierStateful.   Les
  opérations     sur     les     options     sont     écrites     dans
  \textbf{OptionsPayantesPrises}.
\end{itemize}
Les managed  beans récupèrent les  stateless ou stateful beans  par un
lookup dans l’ \textbf{annuaire JNDI}.

Quelques managed beans sont liés entre eux par des injections
configurées  dans  le  fichier  \emph{faces-config.xml}.   Par  exemple  le
managed  bean Panier  est  injecté dans  le  CompteLogin pour  assurer
l’unicité de la session Panier, et implicitement, assurer l’unicité de
l’instance  PanierStateful  spécifique au  client.   Pour mieux  gérer
l’ajout des options payantes pour  une annonce, on a créé une nouvelle
classe \textbf{OptionsPayantesPrises} qui précise pour chaque option, si elle
a été prise ou pas par l’utilisateur.


Nous allons maintenant étudier l'architecture de la partie Contrôle et Abstraction.

\newpage



\subsection{Architecture de la base de données}
\label{sec-3.4}


Un élément central de l’application est l’ \textbf{annonce}, représentée dans la
base  de données  par la  table \textbf{annonceentity}.  Les colonnes  de cette
table  sont des  attributs généraux  pour une  annonce:  titre, texte,
photo,  date (date de  publication), active  (si l’annonce  est encore
affichée sur le site), ville.

La table annonceentity est mappé par l'EJB \textbf{AnnonceEntity}.


Les utilisateurs qui veulent  publier une annonce sont obligés d’avoir
un compte.  Les informations liées aux comptes  sont enregistrées dans
la base de  donnée \textbf{compteentity} dans les colonnes:  pseudo (utilisé au
moment  de l’identification  sur  le site),  mdp (mot-de-passe),  nom,
prenom,  mail, numtel  (numéro de  téléphone), rôle.  Cette  table est
mappée par l’ejb CompteEntity.


 Dans  la   table  \textbf{utilisateurentity}  on   rajoute  des  informations
  spécifiques à la personne,  données représentées dans les colonnes :
  age, datenaissance  (date de naissance),  departement, ville.  Dans
  la version courante de l’application  on s’est limité à une \emph{relation  one-to-one}  entre  utilisateurentity  et  compteentity:  la  colonne
  mycompteentity\_id  de  la   table  utilisateurentity  est  une  clef
  étrangère. Dans les prochaines versions on envisage de faire un seul
  compte  qui  permettra  la  publication  des annonces  en  tant  que
  chercheur et propriétaire, ce qui donnerait une \emph{relation one-to-many}
  entre compteentity et utilisateurentity.  Donc, pour avoir une bonne
  maintenance,  on a  choisi de  créer deux  tables :  compteentity et
  utilisateurentity.  La   table  utilisateurentity  est   mappée  par
  l’entity  bean  UtilisateurEntity  qui  contient un  champ  de  type
  CompteEntity qui sert  à faire la liaison one to  one entre les deux
  tableaux.     Grâce      aux     propriétés     CascadeType.PERSIST,
  CascadeType.REMOVE, CascadeType.REFRESH, associées  au champ de type
  CompteEntity, chaque  changement dans le  compteentity sera transmis
  en cascade à l’utilisateurentity.


Un utilisateur peut être un chercheur, un propriétaire ou un administrateur. A
cause de la différence entre les types d’informations spécifiques pour
ces types, on utilise trois tables
différentes : \textbf{proprietaireentity}, \textbf{chercheurentity} et \textbf{adminentity}.  La table
proprietaireentity      est     mappée      par      l’entity     bean
proprietaireentity. Pour faire la  liaison one-to-one entre les tables
proprietaireentity     et    utilisateurentity,    dans     le    bean
proprietaireentity on  a un attribut de  type UtilisateurEntity. Grâce
aux      propriétés      CascadeType.PERSIST,      CascadeType.REMOVE,
CascadeType.REFRESH   associées   au   champ  UtilisateurEntity,   les
changements dans  la table utilisateurentity  vont être transmis  à la
table  proprietaireentity. La  même logique  s’applique pour  la table
chercheurentity.


Un  chercheur va  créer  aucune,  une ou  plusieurs  annonces de  type
«annonce     chercheur»,      enregistrées     dans     la     table
\textbf{annoncechercheurentity}.  Bien sûr  que les  informations  générales de
l’annonce sont stockées dans la table annonceentity. D’où la relation
one-to-many   entre  chercheurentity  et   annoncechercheurentity:  la
colonne  chercheur\_id\_ce de  la table  annoncechercheurentity  est une
clef  étrangère.   La  table  annoncechercheurentity  est  mappée  par
l’entity  bean AnnonceChercheurEntity.  La relation  one-to-many entre
chercheurentity et annoncechercheurentity est gérée, d’une part, grâce
à  un champ  de type  ChercheurEntity dans  annoncechercheurentity et,
d’autre part,  par une liste de type  \textbf{AnnonceChercheurEntity} dans le
bean ChercheurEntity.


Sur le même principe, un  propriétaire va créer zéro, une ou plusieurs
 annonces de type «annonce propriétaire», enregistrées dans la table
 \textbf{annonceproprietaireentity}. Entre les tables annoncechercheurentity et
 annonceentity  on   a  une  relation  one-to-one.  A   cause  de  ces
 différences  entre   une  «annonce  chercheur»   et  une  «annonce
 propriétaire», on  a représenté  les informations spécifiques  à ces
 deux  types d’annonce dans  deux tableaux:  annoncechercheurentity et
 annoncecheproprietaireentity. La  table annonceproprietaireentity est
 mappée par  l’entity bean AnnonceProprietaireEntity. Ce  bean a parmi
 ses attributs le montant du loyer et la surface à louer. 


 Un chercheur a une liste de zéro, une ou plusieurs annonces favorites
 de type  «annonce propriétaire». Une  « annonce propriétaire » peut
 être dans  la liste des annonces  favorites de zéro,  un ou plusieurs
 chercheurs.    Cette   relation    many-to-many    entre les   tables
 chercheurentity  et  annonceproprietaireentity  est réalisée  par  la
 table  de  jointure  chercheur\_annonceproprietaire. Cette  table  est
 gérée  aux  niveaux  des entity  bean  par  un  champ liste  de  type
 ChercheurEntity dans la classe AnnonceProprietaireEntity, et un autre
 champ    liste   de    type    AnnonceChercheurEntity   dans    L’EJB
 ChercheurEntity.


La  relation  many-to-many  entre  les  tables  proprietaireentity  et
annoncechercheurentity     donne      la     table     de     jointure
proprietaire\_annoncechercheur.


Les  options  payantes  pour  les  annonces vont  être  proposées  aux
utilisateurs en chargeant les entrées de la table optionpayante. Après
que l’utilisateur ait payé les options choisies, on enregistre dans la
table  optionachete  les  informations  liées  à  l’achat:  dateachat,
annonce\_id  (l’id de l’annonce  pour lequel  l’option a  été achetée),
dateFin (date de fin de la validité de l’option), dureedevie (la durée
de  vie de  l’option achetée).  Une option  payante peut  être achetée
plusieurs  fois pour  différentes  annonces, donc  on  a une  relation
one-to-many entre  la table optionpayante et  optionachete. Les tables
optionpayante  et  optionachete  sont  mappées par  les  entity  beans
OptionPayante   et    OptionAchetee,   respectivement.   La   relation
many-to-one entre optionachetee et  AnnonceEntity est gérée grâce à un
champ AnnonceEntity de la classe OptionAchetee, et à une liste de type
OptionAchetee dans le bean AnnonceEntity, respectivement.


La partie  administration du  site est gérée  par les  utilisateurs de
type  administrateurs. La  table adminentity  est mappée  par l’entity
bean \textbf{AdminEntity}.  Les informations générales de  cet utilisateur sont
stockées dans la table utilisateurentity, donc on a une relation
one-to-one entre la table adminentity et la table utilisateurentity.  

\begin{figure}
\begin{center}
%    \input{input}
\includegraphics[height=18cm]{diagbd2.png}
\end{center}
%\label{} 
\caption{Diagramme de la base de donnée de MaColoc}
\end{figure}


\subsection{Paquetage stateful}
\label{sec-3.5}


Sur la partie serveur, le panier est implémenté par un session bean de
type stateful PanierStateful. Dans ce  bean on a une liste d’ItemAchat
qui représente  chaque option qui est  en train d’être  achetée par le
client. Un objet  ItemAchat va stocker l’id de  l’annonce, le titre de
l’annonce et l’option payante.   La partie client de notre application
va  envoyer progressivement  au bean  PanierStateful  des informations
qu’on doit  rajouter ou  enlever dans la  liste d’ItemAchat.  De cette
façon  on évite  d’envoyer dans  une  seule requête  des données  très
lourdes au moment de la validation et du payement panier. La propriété
de  stateful  garantie  la  persistance  de  l’état  de  bean  pendant
plusieurs requêtes du  même client. Pour chaque client,  le serveur va
créer  une  instance  de  stateful  bean.   Pour  rajouter  une  liste
d’options payantes liée à une  annonce dans la liste des ItemAchat, la
partie   client  de   notre   application  va   appeler  la   fonction
rajouterItems du  bean PanierStateful.  Quand on  finalise l’achat, on
va  écrire dans  la table  OptionAchetee pour  chaque  ItemAchat, l’id
d’option payante prise, l’id de  l’annonce associée à cette option, la
date d’achat,  la date de  fin de  la validité et  la durée de  vie de
cette option.  Bien sûr qu’on va  enregistrer cet achat  dans la table
Commandes pour pouvoir récupérer  dans le futur des informations liées
à l’achat.

\subsection{Paquetage stateless}
\label{sec-3.6}

La  liaison entre  la base  de données  et la  partie client  de notre
application (les  managed beans) se  réalise par des session  beans de
type stateless, à l’exception de la gestion du panier qui passe par un
bean  stateful. Les  beans stateless  s’exécutent sur  le  serveur. En
utilisant ce type  d’EJB, l’état du bean n’est  pas conservé après une
requête du  client et on évite  la création de  plusieurs instances du
même EJB pour chaque client.  Plus exactement, sur le serveur, la même
instance  d’un  stateless  bean  peut  gérer des  requêtes  venant  de
différents clients.

Les stateless beans sont structurés selon les fonctions du site.

Pour  gérer  les  deux  types  d’annonce,  pour  un  chercheur  ou  un
propriétaire,   on  a   créé  respectivement   deux   stateless  beans
differens :                AnnonceChercheurStateless                et
AnnonceProprietaireStateless.  On  a  fait  ce  choix  parce  que  les
informations  liées   à  ces   deux  types  d’annonce   sont  vraiment
différentes.


\begin{enumerate}
\item Le bean AnnonceChercheurStateless gère les opérations que l'on peut
\end{enumerate}
faire sur les annonces de type chercheur : création, modification,
activation, suppression  et recherche d’une annonce.   Dans la méthode
CreateAnnonceChercheur      on     persiste     dans      la     table
annoncechercheurentity une nouvelle annonce. Cette méthode prend comme
arguments :
\begin{itemize}
\item un bean de type ChercheurEntity (l’auteur de l’annonce)
\item le titre de l’annonce,
\item son contenu, en texte brut,
\item la ville,
\item une photo (le  nom de  fichier).  La  méthode ModifAnnonceChercheur
\end{itemize}
modifie  les attributs  d’une annonce.  On cherche  l’annonce  dans la
table annoncechercheurentity  par son id,  et après avoir  modifié ses
attributs (son titre,  son texte, la ville, la  photo), on la persiste
en  BD.   La  méthode  ActivateAnnonceChercheur  active  ou  désactive
l’annonce.   Elle  cherche   dans   la  table   AnnonceChercheurEntity
l’enregistrement   pour    l’annonce   avec   l’id    spécifié   comme
argument.  Puis,  après  avoir  changé l’attribut  boolean  «active»
de l’enregistrement retourné  par la recherche, on  fait persister les
modifications dans la BD.


Pour effacer une annonce, on appelle la méthode DeleteAnnonceChercheur
qui prend en  argument l’id de l’annonce de  type chercheur à effacer.
La recherche des annonces dans  la BD peut se réaliser selon plusieurs
critères:
\begin{itemize}
\item la ville - grâce à la méthode FindAnnoncesChercheur qui retourne une
  liste d’annonces spécifiques à la ville choisie. Le seul argument de
  la méthode représente le code postal de la ville.
\item l'utilisateur –  grâce  à la  méthode FindMesAnnoncesChercheur  qui
  retourne une  liste d’annonces spécifiques à  l’utilisateur passé en
  argument.  Cette méthode est  appelée au  moment de  l’affichage des
  annonces crées par l’utilisateur identifié sur le site.
\item l’  id de  l’annonce - grâce  à la méthode  FindAnnonceChercheur qui
  retourne un  bean AnnonceChercheurEntity qui  correspond à l’annonce
  avec l’id passé en argument.
\end{itemize}
La   méthode  FindAnnoncesChercheur()   retourne  tous   les  annonces
enregistrées dans la table AnnonceChercheurEntity.

\begin{enumerate}
\item Le bean  AnnonceProprietaireStateless gère  de la  même  façon les
\end{enumerate}
opérations qu’on puisse faire sur les annonces de type propriétaire :
création,  modification, activation,  suppression  et recherche  d’une
annonce.  La méthode  CreateAnnonceProprietaire persiste un annonce de
type  propriétaire   dans  les  tables   annonceproprietaireentity  et
annonceentity. Cette méthode prend comme arguments
\begin{itemize}
\item un bean de type ProprietaireEntity (l’auteur de l’annonce)
\item le titre de l’annonce,
\item son contenu texte,
\item la ville,
\item la surface,
\item le prix de loyer,
\item une photo.
\end{itemize}
La  méthode  ModifAnnonceProprietaire   modifie  les  attributs  d’une
annonce.     L’annonce     est     recherchée    dans     la     table
annonceproprietaireentity  par  son  id  et après  avoir  modifié  les
attributs de l’annonce  (le titre, le texte, la  ville, la surface, le
loyer la photo), on la persiste dans la BD.


La    méthode   ActivateAnnonceProprietaire   active    ou   désactive
l’annonce.  Elle  cherche   dans  la  table  AnnonceProprietaireEntity
l’enregistrement   pour    l’annonce   avec   l’id    spécifié   comme
argument.   Puis,    après   avoir   changé    l’attribut   «active»
de l’enregistrement  retourné  par   la  recherche,  on  persiste  les
modifications dans  la BD.   Pour effacer une  annonce, on  appelle la
méthode  DeleteAnnonceProprietaire  qui  prend  en  argument  l’id  de
l’annonce de  type propriétaire à effacer.  Les  critères de recherche
des annonces de type propriétaire dans la BD restent presque les mêmes
que pour une annonce de type chercheur, selon :
\begin{itemize}
\item la ville - grâce  à la méthode FindAnnoncesProprietaire qui retourne
  une  liste  d’annonces  spécifiques  à la  ville  choisie.  Le  seul
  argument de la méthode représente le code postal de la ville.
\item l’utilisateur  – grâce à la  méthode FindMesAnnoncesProprietaire qui
  retourne une  liste d’annonces spécifiques à  l’utilisateur passé en
  argument.  Cette méthode est  appelée au  moment de  l’affichage des
  annonces crées par l’utilisateur identifié sur le site.
\item l’ id de l’annonce  - grâce à la méthode FindAnnonceProprietaire qui
  retourne   un  bean   AnnonceProprietaireEntity  qui   correspond  à
  l’annonce avec l’id passé en argument.
\end{itemize}
La  méthode   FindAnnoncesProprietaire  retourne  tous   les  annonces
enregistrées dans la table AnnonceProprietaireEntity.


Pour gérer les deux types d’utilisateurs qui peuvent s’enregistrer sur
le site, on a deux stateless beans : ChercheurStateless et
ProprietaireStateless.

\begin{itemize}
\item \textbf{ChercheurStateless}  : au moment de  la création d’un  compte de type
  chercheur, on  appelle la  méthode create du  ChercheurStateless qui
  prend parmi ses arguments le  pseudo (l’identifiant sur le site), le
  mot de passe  et le rôle de l’utilisateur  (pour faire la différence
  entre les  comptes de type  administrateur et les comptes  dédiés au
  grand public).  Après que l’utilisateur chercheur a créé une
  annonce, on associe cette nouvelle  annonce à son auteur en appelant
  la méthode  addAnnonce.  La suppression du compte  de type chercheur
  se fait grâce à la méthode deleteCompte.
\item \textbf{ProprietaireStateless}  : Le  bean  ProprietaireStateless offre  les
  mêmes  fonctionalités que  le ChercheurStateless,  mais bien  sûr en
  adaptant  le  code au  type  des  données  spécifiques à  un  compte
  chercheur.  On a les mêmes méthodes : create, addAnnonce,
  deleteCompte.
\end{itemize}
Le bean  OptionPayanteStateless gére l’affichage  des options payantes
qui  sont  offertes  par  le site.  La  méthode  getListeOptionPayante
retourne  une  liste  avec   tous  les  enregistrements  de  la  table
optionpayante.


Le   stateless  bean   TestGetIdentifier  offre   une   seule  méthode
getUserName qui sert  à recuperer l’identifiant d’utilisateur connécté
sur le site.


\begin{itemize}
\item \textbf{AmdinStateless}  :  les  actions  spécifiques  à  l’administrateur
  passent  par le  stateless bean  AdminStateless. Ce  bean implemente
  différentes  méthodes pour gérer  tous les  annonces et  les options
  payantes : printAnnoncesChercheurs, printAnnoncesProprio,
  modifyPriceOptionPayante,
  modifyLifeCycleOptionPayante,removeOptionPayante.
\end{itemize}
La méthode  \emph{PrintAnnoncesChercheurs} permet de  consulter et d’afficher
l’ensemble  des annonces  existantes dans  la base  de données  et qui
correspondent aux différents chercheurs.


La méthode  \emph{PrintAnnoncesProprio} permet de consulter  et d’afficher la
totalité des annonces existantes dans la base de données, publiées par
les différents propriétaires.


La méthode  \emph{ModifyPriceOptionPayante} permet de modifier  le prix d’une
option payante faisant partie  de l’ensemble des options proposées aux
clients. Cette  méthode prend en paramètres un  entier représentant le
nouveau prix.

La méthode \emph{ModifyLifeCycleOptionPayante}  permet de modifier la durée
de vie d’une  option payante faisant partie de  l’ensemble des options
proposées  aux clients. Cette  méthode prend  en paramètres  un entier
représentant la nouvelle durée de vie à attribuer.


La  méthode  \emph{removeOptionPayante}  permet  de  supprimer  une  option
payante  de la  liste proposée  aux clients.  Elle prend  en paramètre
l’option à supprimée (identifiée par son id).  

La   méthode
\emph{removeAnnonceChercheur} permet de supprimer une ``annonce chercheur''
en lui passant l’id de l’annonce à supprimer en paramètre.


La  méthode \emph{removeAnnonceProprio} permet  de supprimer  une ``annonce
propriétaire''  en  lui  passant  l’id  de  l’annonce  à  supprimer  en
paramètre.


\subsection{Paquetage api}
\label{sec-3.7}

Ce paquetage offre les interfaces remote implémentées par les sessions
beans de type  stateless ou stateful. Dans ces  interfaces on a défini
les méthodes utilisées par un client distant. On a les interfaces :


\begin{center}
\begin{tabular}{ll}
 Interface \ldots{}             &  \ldots{} implémentée par :    \\
\hline
 IAnnonceChercheurRemote        &  AnnonceChercheurStateless     \\
 IAnnonceProprietaireRemote     &  AnnonceProprietaireStateless  \\
 IChercheurRemote               &  ChercheurStateless            \\
 IProprietaireRemote            &  ProprietaireStateless         \\
 IOptionPayanteStatelessRemote  &  OptionPayanteStateless        \\
 ITestGetIdentifier             &  TestGetIdentifier             \\
 IPanierStatefulRemote          &  PanierStateful                \\
 IAdminStatelessRemote          &  AdminStateless                \\
\end{tabular}
\end{center}





                        



\subsection{Autres services}
\label{sec-3.8}

\begin{itemize}
\item \textbf{Stockage des photos} : les photos uploadées par les utilisateurs sont
  stockées dans le répertoire ecom/src/main/webapp/Photos.
\item \textbf{jaas}   :  pour  assurer  la  sécurité   de  l’authentification  des
  utilisateurs on  utilise le  module de login  défini par JAAS  et un
  \emph{CallbackHandler}        fourni         par        le        paquetage
  org.objectweb.jonas.security. Ce handler est integré dans le serveur
  JOnAS, ce qui donne plus de  robustesse à notre site. Ce handler fait
  la  liaison  avec  la  table   compteentity,  où  on  a  défini  les
  identifiants des utilisateurs, leur mot de passe et leur rôle.
\end{itemize}

\end{document}